Thanks for submitting this PR, @vivenstrix — we appreciate it!

Could you share a bit more about your use case for running a local MCP server via Docker instead of using our remote MCP option (https://mcp.supabase.com/mcp)?

Understanding the motivation would help us evaluate the change more effectively.

For reference, our documentation on setting up the remote MCP server is available here:
https://supabase.com/docs/guides/getting-started/mcp#remote-mcp-installation

Hey Pedro,

One of the main reasons I went down this path is that when I was looking for the Supabase MCP server in Docker MCP server catalogs / registries, it wasn’t there. Since I use Supabase heavily across a lot of my projects (backend APIs, Postgres, auth/OAuth, etc.), I wanted a clean and consistent way to expose those capabilities to my tooling.

More specifically, my goal is to have a single MCP server configured in Cursor — the Docker-based MCP server — and then let that server provide access to the tools it exposes (like Supabase) behind the scenes. That way I don’t have to register multiple MCP servers directly in the editor.

This helps with a couple of things in practice, avoids overloading Cursor with many MCP servers at once, keeps the context window smaller and more focused. Makes the setup more modular, especially when working with multiple backends, fits better with Docker-based MCP registries and workflows.
I’m not trying to replace or compete with the remote MCP option — that’s still a great default. This is more about enabling a local / containerized option for people who want tighter control over how MCP servers are composed and exposed to their editor.

Hope that helps clarify the use case

@Rodriguespn Just wanted to follow up and see if this would be approved or denied?